REMARKS 

Applicants' attorney is appreciative of the interview 
granted by the Examiner to the undersigned and to Applicants' 
represetative Deborah Gador on February 14, 2007. At that 
interview, Applicants' attorneys discussed how the packets 
formed according to the invention contain segments of services 
having different protocols. 

Claims 19 and 12-16 have been rejected under 35 USC 112, 
1 st paragraph, as containing subject matter not described in 
the specification. In particular, it is alleged that the 
specification as originally filed- does not describe or 
illustrate two service ports. Claim 19 has been amended to 
delete the reference to two service ports, and withdrawal of 
this rejection is requested. 

Claims 1, 3, 4, 7-10, 12-20 have been rejected under 35 
USC 102(e) as being anticipated by US 6,331,978 to Ravikanth, 
and claims 2, 5, 6, 11 have been rejected under 35 USC 103(a) 
as being obvious over Ravikanth in view of the article to 
Ndousse . 

The Office Action alleges that Ravikanth discloses a 
method for packet processing comprising adding a label to the 
front of a datagram, where adding a label is interpreted as 
adding a tag, and where the datagram is interpreted as a 
segment. The presence of a datagram has also been interpreted 
as being preceded by a -form of segmentation of a bit stream of 
data of at least one service. Regarding claim 18, it is 
alleged that Ravikanth implicitly discloses receiving datagram 
of multiple services, pointing to column 5, lines 14-17. 

The invention relates to a method for packet preparation 
and processing for transmission of various types of data 
services (e.g., data, voice, video, etc.) over an optical 
fiber. For purposes of the invention, "services" refers to 
so-called "native services." Examples of native services, 
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each having its own bit rate and protocol, are illustrated in 
the application (TDM, ATM, Ethernet, Fibre Channel, PDH, 
Frame-Relay), as well as in the definition of Pseudowire (PW) 
in Wikipedia, copy attached hereto, as follows: M PW is an 
emulation of a native service over a Packet Switched Network 
(PSN) . The native service may be ATM, Frame Relay, Ethernet, 
low-rate TDM, or SONET/SDH, while the PSN may be MPLS, IP 
(either IPv4 or IPv6), or L2TPv3." 

Conventional packets are known only for certain data 
services, particularly Ethernet and Fibre Channel packets. 
Other services, such as voice and video streaming services, 
among others, cannot be inserted, as they are, into these 
types of packets. Rather, they must be converted to another 
protocol, such as IP protocol, in order to be inserted into a 
transmission frame. As stated in the Background of the 
Invention (page 1, lines 16-19), at present, data according to 
each protocol must be transmitted via its own network, and 
data at different bit rates must be transmitted separately or 
converted to another protocol before being transmitted 
simultaneously with other data rates and/or types over a 
higher bit rate medium. Thus, in conventional methods, two 
additional steps (conversion and re-conversion) are required 
in order to permit more than one service to be transmitted 
together . 

The heart of the invention thus lies in combining 
different services, in their original protocols, into the same 
packet, in order to provide improved utilization of the 
available bandwidth. This is accomplished by receiving and 
identifying incoming bit streams of data containing at least 
two services (one service per bit stream) , segmenting each bit 
stream in its original protocol into variable length segments, 
and adding a tag to each segment to identify the service of 
the segment. Tagged segments from two or more bit streams are 
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processed into a single packet, which can act like a 
conventional Ethernet packet (see page 6, lines 4-7), even 
though it has different services inside in their native (i.e., 
original protocol) form (page 3, lines 23-25) . If it is 
desired to transmit these packets in a conventional 
transmission frame, the method may further include the 
conventional steps of adding a routing tag to each packet and 
inserting a plurality of packets into a transmission frame for 
transmission. 

The invention, by creating packets having at least two 
different services therein, permits one or more services, in 
their original protocols, coming from at least two bit 
streams, and possibly more, to be divided up into different 
size units, so that "empty" spaces on the bandwidth can be 
filled, thereby increasing efficiency of the overall system 
(see page 3, lines 20-22). This method is not taught or 
suggested in any of the prior art known to Applicants or cited 
in the Office Action. 

This method, and an engine for carrying out this method, 
have been more precisely claimed in amended claims 17 and 19. 
Specifically, the claims have been amended to indicate that 
incoming bit streams containing at least two services are 
identified (by their source and destination addresses) and 
segmented, and each segment is provided with a tag identifying 
.the service in- the segment. Tagged segments of at least two 
services are inserted into a single packet. 

According to one embodiment of the invention, claimed in 
new claim 21, this formed packet then receives a routing tag 
and is inserted, with other packets, into a transmission 
frame. Support for these claims is found, inter alia, on page 
8, lines 1-7, and 17-19. 

As explained in detail during the interview, the patent 
to Ravikanth relates to a generic label encapsulation protocol 
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for carrying IP packets (packet-based services) . This protocol 
utilizes datagrams, which are pre-formed conventional data 
packets, and adds a routing tag for improved efficiency of 
routing of the packets through the network. There is no 
teaching or suggestion of combining two or more services into 
a single packet, as claimed. Rather, the Ravikanth method is 
merely one method by which existing or pre-formed packets can 
be routed through a network. 

Ravikanth deals with Ethernet services which are sent via 
IP protocol only. There is no need for a label identifying the 
service inside the packet (third step of amended claim 17), 
since only one type of service is sent over Ravikanth f s 
network; only a routing tag is necessary. Further, Ravikanth 
cannot transport voice services, video streaming services, 
storage services such as Fibre Channel services, for example, 
since they are not label switched packets. Thus, he can send 
Ethernet services from any protocol layer (e.g., IP, MPLS), 
but not different services as defined in the present 
application. In fact, as stated above, the packet based 
services which are provided as datagrams in Ravikanth can be 
segmented according to the invention and formed into the 
packets of the invention alone, or with other types of 
services . 

The Office Action further states that Ravikanth discloses 
that SONET is used for data transmission over optical fibers. 
SONET (and SDH) in this usage is a transport protocol. This 
means that data TDM and packet data can be converted to SONET 
protocol and transmitted in a SONET transmission frame. 
Packets of the invention can also be sent over SONET as a 
transport medium, or over MPLS as a transport medium, over 
another conventional transport medium (or over their own 
network) . In the case of SONET, MPLS, and other conventional 
transport protocols, an address label or tag is added to the 
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novel packet, and the packet is converted to the transport 
protocol, as claimed in new claim 21. 

In addition, those skilled in the art will appreciate 
that, for purposes of the invention, SONET/SDH is also a 
"service" in itself, and can be segmented and inserted into 
packet according to the invention. Thus, the invention is 
directed a method for multiplexing (combining together) at 
least two different services into a single packet. According 
to the invention, segments of bit streams of voice services 
can be combined with segments of streams of video streaming 
services and with segments of streams of Ethernet (packet- 
based) services. This capability is not provided by any art 
known to the Applicant or cited in the Office Action, 
including Ravikanth. The claims as amended more clearly claim 
this distinction, claiming segmenting at least two bit 
streams, each bit stream of one service, where the bit streams 
can be the same services or different services. 

The Ndousse article on PPP Extensions examines the 
dynamics of IP traffic over SONET/SDH using PPP in HDLC-like 
framing. There is no teaching or suggestion in Ndousse of the 
method of forming packets, as claimed in amended claims 17 and 
19. Applicants are not claiming encapsulating a packet into a 
PPP-HDLC frame, per se, but only in the context of the method 
of claim 17 and the system of claim 19. 

Regarding, the Response to 1 Arguments, the above 
explanation is thought to have clarified that pre-formed 
datagrams are indeed different from the packets of the 
invention, most certainly in the method by which these packets 
are created. 

The Office Action points to the non-limiting Example in 
the specification which utilizes an Ethernet frame as a 
"segment" for purposes of creating a packet. The segments- 
according to the invention can have variable length between 
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and within a particular service; see page 6, lines 11-16. 
Thus, while the length of the bit stream selected for a 
segment may be the length of an Ethernet frame in its 
entirety, the bit stream could, alternatively, be cut into 
segments of smaller or larger size than an Ethernet frame, 
starting at the- beginning or in the middle of the frame, as 
desired at the time. In this way, the length of the segments 
may be determined at the time of filling the packet, so as to 
fill, as completely as possible, the bandwidth in each frame. 

The Office Action has noted that the specification does 
not support cutting a frame into several segments. The 
specification does, however, support segmenting a bit stream 
into variable length segments which, as stated above, may or 
may not start or end in the same place as an Ethernet frame, 
or a TDM time slot or an ATM cell. 

It is also noted that "class of service" does not refer 
to type of service, as defined in the invention, but rather to 
level of priority given to certain types of traffic in service 
provider agreements. Thus, the addition in Ravikanth of an 
MPLS label indicating class of service does not identify 
source or destination or type of service, but only what 
priority the data is given during transmission. 

Withdrawal of these rejections is requested. 

In view of the foregoing amendments and remarks, 
Applicants submit that the present application is now in 
condition for allowance. An early allowance of the 
application with amended claims is earnestly solicited. 




pectfully submitted, 



Registration No. 28666 
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